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Abstract 

In order to develop quality control software for mul- 
tiple robots , a common interface is required. By de- 
veloping components in a modular fashion with well- 
defined boundaries , roboticists can write code to pro- 
gram a generic rover, and only require very simple 
modifications to run on any robot with a properly im- 
plemented framework . The proposed framework ad- 
vances a GenericRover that could be any rover , from 
Real World Interface's All Terrain Robot Vehicle Jr. 
series, to the Fido-class rovers from the Jet Propul- 
sion Laboratory , to any other research robot. Using 
these generic hardware interfaces , software designers 
and engineers can concentrate on the actual code, and 
not have to worry about hardware details. In addition 
to the hardware support framework , 3 sample applica- 
tions have been developed to demonstrate the flexibility 
and extensibility of the framework. 

1 Introduction 

Every robotic rover architecture relies on some dis- 
tributed mechanism to share rover data and to issue 
commands. However, these independent architectures 
are very hardware dependent and are not easily ex- 
tensible to different rover platforms. The proposed 
framework allows high-level software to be written to 
support a reference rover. Through the use of well- 
defined features anti interfaces, high-level controllers 
need not be concerned with hardware dependencies. 
To support this framework, a foundation layer is re- 
quired to transform high-level commands into the re- 
quired hardware interface for the rover. 

The proposed framework w;us designed to support 
Re;d World Interface's ( RAVI) All Terrain Robot Vehi- 
cle (AL RV)-.Jr. robot, but could be easily extended to 
any control interface. Every detail of the rover is hier- 
archically descended from a bitsir rover object. Follow- 


ing previous work in the group, commands may be sent 
to the physical hardware via standardized messages; 
for convenience, the K9 rover messages w^ere used as 
templates. In the case of the ATRV-.Jr.. the hardware 
framework is responsible for translating these high- 
level messages into Common Object Request Broker 
Architecture (CORBA) operations. CORBA is used 
as an object transport by default; the commercially 
supported control system aboard the ATRV-Jr. com- 
municates via CORBA. By using asynchronous com- 
mand queues to process rover requests, most frame- 
work calls return to their calling function very quickly, 
generally only requiring a memory copy. 

Distributed operation is handled transparently by 
the CORBA object transports, concurrently allowing 
multiple disparate clients to issue requests to the rover 
and observe the state. Much of the work of the base 
class involves translating robot data to appropriately 
standardized common output values. For example, 
the CORBA components for the Inertial Measurement 
Unit (IMU) provide one integration step of accelera- 
tion data; the framework then interpolates the second 
required integration to provide a rough estimate of 
position. 

2 Hardware Support 

2.1 Hardware to CORBA Interface 

Because of the modular design ot CORBA, certain 
components can be replaced with higher-performance 
implementations. In the ATRV Jr., the only com- 
ponents that are not driven by serial port are the 
ston*o framegrabbers, which connect via two Periph- 
eral Component Interconnect (PCI) bus slots. These 
framegrabbers are commercially available Hauppaugc 
WinTV NTSC cards that utilize a Brook tree 878 
chipset. The original code provided by R\V I used a 
single-threaded, single buffering caprure scheme which 



a.s controls on rot. it inn and t ranslath m. Tin* results of 
:'»i mav be useful To integrate info the I wise eout roller, 
us r. 1 1 « * sensors available on Kd .in* very similar to the 
sensors of tin* ATRV-Jr. 

3.2 Resolution 

Tin* calibration setup was needed to correct for a 
problem that wa s only observed in field tests that re- 
lated to the difference between a turn command and 
the actual result of the command. These commands 
were given by hand and thus were directly observable; 
the same class of commands is used by the sample 
tracker described below and thus need to become more 
accurate. The model of the base drivetrain that is ex- 
posed by RWTs software does not expose raw wheel 
counts, and appeared calibrated for non-ablative sur- 
faces such as solid floors. On such surfaces, turns are 
much more accurate than for turns on gravel. 

A basic calibration is proposed to determine linear 
coefficients of the rotational and translational veloci- 
ties to characterize a surface's requirements for accu- 
rate motion. Also, because the work of [5| is available 
for integration into the base controller, a combination 
approach might give the best results. 

4 Sample Applications: Utilities 

4.1 groven A Rover Control Utility 

grover was design ed to exercise all of the possible 
functions of all of the rover extensibilities. The com- 
mand line interface is suited to directing the robot 
through a series of low-level operations. In essence, 
the purpose of this application is a test and utility 
driver that can issue specific commands for adjusting 
the rover’s state. Foe example, this utility was used 
in the proving tests to issue specific drive commands 
and to adjust the pantilt head to specific values. Also, 
grovtir was used to capture imagery used by E. Ban- 
dari and E. Ricks of the Autonomy and Robotics Area 
(ARA) to characterize the vision system aboard the 
rover. 

4.2 panovision: A Telemetry and Imag- 
ing Utility 

To demonstrate the flexibility of the framework, 
arid to support other researchers in the Autonomy and 
Robotics Area, panovision was implemented. A com- 
mercially available* camera was placed into an optics 
package manufactured by Carnegie Mellon University 



Figure 2: CMU Omnicam aboard ATRV-Jr. 


(CMU) ro provide a full 360 degree field of view. The 
complete enclosure was then mounted on the ATRV-Jr 
using a custom manufactured mount. (Figure 2) 

The chosen camera is a Sony E VI-370 D block cam- 
era that has a serial interface to adjust camera param- 
eters and a NTSC video output. By reviewing tech- 
nical material provided by Sony and modifying source 
cotie provided by CMU;T. a library of camera con- 
trol functions was developed,. Some functions include 
adjustable zoom, focus control, ami exposure control. 


4.2.1 Telemetry Control 

Id facilir.ire other research, rover telemerry had to 
be captured bv interrogatin'.! various hardware com- 
ponent* wirhin a fr ame ni reference, f his hardware 
requirement was icn auplids d I »v u*i ug T he developed 
framework. In addition. asM.uung t proper m.plemon- 
tal ion was available ii.r another rover, oulv e.perhcial 
mod ifieat blh Would a* liere^surv to I" 1 1 1 1 t IJ* Ullage 
ca pr u re and o 'let tier r v < aj w ii'v i >u tnot her platform. 



Disparity and Prediction Measure 


I'm uljusf fur pitching terrain. r ! 10 • >nl>nard pitch 
sensor is utilized. [ n r In * framework, a relative tilt is 
defined to be the rilt angle of tlie pan-tilt head with 
respect to the rover body; ait apparent tilt is defined 
to be the Lillie between the optical axis of the camera 
and tlie surrounding terrain, using a planar assump- 
tion. This apparent tilt can be calculated by summing 
the reading from the pitch sensor and the tilt reading 
from the pan- tilt head. By using the readings from 
the pitch sensor, the rover can compensate for uneven 
terrain and correct artificially high or low relative tilt 
angles. 


Because rhr rover is moving wilh ih' iriv constant 
f r .mdattonal speed, a further -mbaur-aiient of the 
rr u ker would lx* ro predict the location of rlie tar- 
get in rhe next frame. Bv assuming a linear model of 
movement, the target disparity, or rhe durance from 
rlie Target to the center point of rite image, is mea- 
sured and recorded. Using a simple approximation, 
rlie next locarion of the target in the source image is 
predicted. Due ro insufficient resources. r his informa- 
rion is calculated and stored for further uialysis. but 
m>r integrated into the tracker conrrol !ui»p. 


5.3 Finish Conditions 


Once the tracker could analyze an image and report 
on the best possible match of the target, the frame- 
work was utilized to center the target in the field of 
view and to issue a drive command to the base. In or- 
der to determine when the rover has actually reached a 
target, the measure of the apparent tilt angle defined 
above is used. Presumably, when a target is within 
range of an on-board instrument, the pan- tilt will be 
’’looking” downward beyond a specific, predefined an- 
gle. 


5.4 Role of Subcapture 


Using the subcapture capability described above, 
the performance of the tracking algorithm was in- 
creased by limiting the search space. In every iter- 
ation, the rover seeks to minimize the absolute pan 
angle and keep the target centered in the image plane. 
Once the rover has met these objectives, the possible 
search space is limited" to one quarter of the size of the 
initial space to increase tracking performance. 

Due to the distributed nature of the vision system, 
a possible conflict exists where a request to change the 
subimage may occur, but does not take effect instan- 
taneously. The result of such a conflict is that the 
returned imagery is from a different section of the im- 
age than the specified coordinates requested. To pre- 
vent this conflict, the vision object pauses the tracker 
until the requested image coordinates are available. 
Tlie pause operation is transparent to the visual servo- 
ing client and is provided by tlie particular framework 
implementation. This operation is done at the low- 
est possible level to reduce tlie communications band- 
width required by imaging operations. 


5,6 Tracker Performance 

An operator selects a target using an initial im- 
age at the full working resolution of tlie camera. The 
tracker loop then drives the rover towards the target, 
logging an image during every iteration. During full 
resolution operation, the tracker loop can run at ap- 
proximately 2 Hz. During subimage operation, the 
loop speed increases to approximately 5 Hz. 


5.6.1 Laboratory 

In laboratory tests, the tracker’s performance is capa- 
ble of driving the rover at speeds of up to 20 cm/s. 
See Figures 3, 4. and 5 for starting, intermediate, and 
ending points. The operator-designated target is sym- 
bolized by a crosshair in 3: the rover's estimates are 
in 4 and 5. The performance of rhe tracker in the lab 
setting is sufficiently good to warrant further investi- 
gation: however, the laboratory setting makes use of 
controlled lighting and a well-defined textured target, 
the phone directory of the Center. 



Figun* 4: Lab lest Begin 




Figure 3: Field Test Complete 


an extensible control and reporting interface for any 
type of rover that has the same logical functions. For 
example, most rovers have capabilities such as moving 
a pan-tilt head, moving the drivetrain and chassis, and 
retrieving current rover state. 

Any software which needs to have access to rover 
control need only host a framework object, allow- 
ing user interface development to become indepen- 
dent from object transport development. Essentially, 
the framework establishes a local set of objects that 
proxy requests to the rover, hiding the underlying ob- 
ject transport from the developer. Through the use of 
such abstractions, any rover could be supported in a 
transparent fashion. 

In addition, by using CORBA over Transmission 
Control Protocol; Internet Protocol (TCP/IP) as a 
distributed object transport, any operation can be ini- 
tiated by any machine that has IP connectivity to the 
rover. As a side benefit, several CORBA implementa- 
tions are freely available, negating the direct or hidden 
licensing costs associated with other distributed object 
models. 

Many further developments are envisioned. For ex- 
ample, a generic simulation rover that conforms to the 
framework and provides rnorkup data and telemetry 
would be useful for testing rover control software of- 
fline. in a device independent fashion. Control soft- 
ware under development can support any rover that 
luus b/isir functions: components that require special- 
ized control such as arm control or other device control 
ran simply extend the framework in the appropriate 
direction for the appropriate hardware platform, [n 
this ra.se. oiilv rover-spec ifir rode would need to be 
written; core fuurtioiialiry would he provided by the 
framework and the framework's underlying hardware 


implementation. 
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